Subject: DLSw scalability proposal comments

From: [email-masked]
Date: Mon, 16 Sep 96 13:03:14 EDT

I have the following comments about the Aug. 23 draft (plus
latest comments):

1) First, I have a question about what we are being asked to
   give AP approval on.  Is it the scalability proposal alone
   or is it all of the 1.1 function?
   Paul, maybe you can help with this one.

2) last paragraph of the "Single Session TCP/IP Connections"
   section .....

   The lines "As an optional enhancement, however, multicast ....
   the newly established TCP connection." need to be modified.

   At the last AIW, we discussed that many DLSw implementations
   bring up both TCP connections before doing capabilities exchange.
   This being true, the optional enhancement discussed in this
   paragraph is not feasible.  At the AIW, a proposal was discussed
   in which DLSw implementations supporting the 1.1 function could
   use a new read port of 2067 to eliminate the need to bring up
   both TCP connections and then dropping one.

   Prior to going to AP status, I think that we should either
   review/approve this written proposal or document that there will be
   no such proposal.  The above lines should then reflect the
   outcome.  Since it is my understanding that we are trying to
   achieve AP status on all 1.1 function, I do not see how we
   can give electronic AP approval until this is resolved.

3) "UDP SSP Packet Handling" section

   This section is confusing to me.  The only SSP message that I
   am aware of that portions of the frame can be parsed separately
   (and skipped over if not recognized) is the Capex SSP message.
   But this message is not one of the allowed UDP SSP messages.
   I think the statement referring to skipping portions of a UDP
   SSP message should be removed.

4) NetBIOS transport chart updates

   I believe the following two changes should be made to the chart.
   - STATUS_QUERY: change Unicast/Multicast to Unicast/Multicast2
   - NAME_QUERY: change Unicast/Multicast to Unicast/Multicast2
   Note2 applies to these types of NetBIOS frames as well as the DATAGRAM.
   Note2 should also be modified to not specifically reference DATAGRAM frames.

5) Change to vendor specific UDP packet formats

   I agree with the proposal to add the message length field back in.

   The only question that I have is - do we want to define exactly what
   header length and message length fields are?  More specifically, is
   header length the length up to the end of the OUI or can it be longer?

   I am assuming that header length and message length can be anything that
   we want given that header length + message length = total data length,
   and the header length is at least 7 bytes (includes defined info).

6) Miscellaneous typos

   - "Single session TCP connections" section; first paragraph, first sentence .
   - "Using Multicast Groups" section; first paragraph, second sentence ....
   - "Unicast UDP Datagrams in Lieu of IP Multicast" section; second paragraph,

     change "chose" to "choose"

   - "Multicast Groups and Addressing" section; second paragraph, second sentenc

     change "carefully" to "careful"

   - "Vendor Specific Functions over UDP"; second paragraph, first sentence ....

     change "set of DLSw" to "set of DLSws"

   - "Capabilities Exchange" section; second paragraph, last sentence ....

     missing period

   - "Communicating with multicast capable nodes" section; second paragraph, las

     change "inaccordance" to "in accordance"

   - "Explorer frames" section; first paragraph, second sentence ....

     change "NAME_RECOGNIZED_ex" to "NETBIOS_NR_ex"

   - "NetBIOS" section; Note 3; first paragraph, second sentence ....

     change "NAME_RECOGNIZE" to "NAME_RECOGNIZED"

   - "NetBIOS" section; Note 4; first paragraph, second sentence ....

     change "aSTATUS_QUERY" to "a STATUS_QUERY"

Thanks for all of your work.

Jon Houghton (IBM Corporation)

---

From: Stephane St-Hilaire <[email-masked]>
Date: Tue, 17 Sep 96 13:39:00 PDT

>>   paragraph is not feasible.
I don't understand how this enhancement is not feasible ?

>>    SSP message should be removed.
Well that section was probably put there to prepare for future message   
types so the only question is: What would we gain by removing it ?

>>    header length the length up to the end of the OUI or can it be   
longer?
The document mentions that it can be other than 72, so the header lenght   
can probably be anything from 7 to 255.

>>       and the header length is at least 7 bytes (includes defined   
info).
That's how I see it too. I'm not sure that we need to explain the meaning   
of these lenghts fields further since RFC 1795 uses the same terminology   
(header lenght and message length) with sufficient information we (may)   
need to add one more reference to RFC1795 in this section...

Stephane St-Hilaire (Eicon Technology)

 ----------
From:   
 aiw-dlsw-scalability[SMTP:[email-masked]]
Sent:  Monday, September 16, 1996 1:15 PM
To:  stephanh
Subject:  DLSw scalability proposal comments

   I believe the following two changes should be made to the chart.
   - STATUS_QUERY: change Unicast/Multicast to Unicast/Multicast2
   - NAME_QUERY: change Unicast/Multicast to Unicast/Multicast2
   Note2 applies to these types of NetBIOS frames as well as the   
DATAGRAM.
   Note2 should also be modified to not specifically reference DATAGRAM
frames.

   I am assuming that header length and message length can be anything   
that
   we want given that header length + message length = total data length,
   and the header length is at least 7 bytes (includes defined info).

6) Miscellaneous typos

   - "Single session TCP connections" section; first paragraph, first
sentence .
   - "Using Multicast Groups" section; first paragraph, second sentence   
....
   - "Unicast UDP Datagrams in Lieu of IP Multicast" section; second
paragraph,

   - "Multicast Groups and Addressing" section; second paragraph, second
sentenc

   - "Vendor Specific Functions over UDP"; second paragraph, first   
sentence
....

   - "Capabilities Exchange" section; second paragraph, last sentence   
....

     missing period

   - "Communicating with multicast capable nodes" section; second   
paragraph,
las

---

From: [email-masked]
Date: Wed, 18 Sep 96 09:38:17 EDT

Stephane,  Thanks also for these comments.  Replies below.

Jon Houghton

>> ------------------------------- Referenced Note ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>    Tue, 17 Sep 96 13:44:40 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>>           id AA21935; Tue, 17 Sep 1996 13:44:17 -0400
>> Date: Tue, 17 Sep 1996 13:44:17 -0400
>> Message-Id: <[email-masked]>
>> Errors-To: [email-masked]
>> Reply-To: [email-masked]
>> Originator: [email-masked]
>> Sender: [email-masked]
>> Precedence: bulk
>> From: Stephane St-Hilaire <[email-masked]>
>> To: [email-masked]
>> Subject: RE: DLSw scalability proposal comments
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>> X-Comment:  DLSw scalability issues
>>
>>

RFC 1434 implementations do not sent Capex at all.

Most, if not all, RFC 1795 implementations wait until both TCP
connections are active before sending Capex.

So, if we choose to try to implement an enhancement in which
we only bring up one TCP connection and wait for the Capex from
the partner to determine whether to bring up the second TCP
connection, it will not be compatible with most current 1434 and
1795 implementations.

If you receive an TCP open indication and immediately send out a
Capex without bringing up the other TCP connection, the following
will happen:

If the partner is a 1434 box, it does not process the Capex;
 your box receives nothing.

If the partner is a current 1795 box, it does not send a Capex until
 your box has opened the second TCP connection; your box receives nothing.

If the partner is a new 1795 v1.1 box, it could send a Capex immediately
 upon receiving the Capex.

So, you would either receive nothing or a Capex indicating you can support
 multicast.  The problem is .... how long do you wait before you know you
 have received nothing and must bring up the second TCP connection.
 For NetBIOS, we don't have time to wait.

At the AIW, it was determined by the group that the most feasible way
to solve this problem would be use a different read port.

>> types so the only question is: What would we gain by removing it ?

The problem is that I can not implement anything at this point based upon
this statement.  Until I know what messages are of this format and what the
format is - I can't do anything.  So I ask the opposite - what do we gain
by leaving it?  I read it and assume that there is something I should
implement based upon it - and there's not.

>> can probably be anything from 7 to 255.

My assumption too - can we state it.  Actually, I assume it is 7.

>> need to add one more reference to RFC1795 in this section...

RFC 1795 says header length is 72 or 16 and the message length is the
number of bytes following the header.
So, based upon this I would assume the header length is 7 (or 8 if we add
message type) and the message length is length of everything beyond.
Is this your assumption?

The only important point I have here is that the message length was added
to the DLSw UDP OUI header to cover the case in which one of these messages
ends up in the TCP stream.  If this happens, we'd better know what the total
length of the stream is - not assume we all know.

I'm not proposing we define in great detail what all the fields in the DLSw
UDP OUI header are, but if it doesn't matter what is in these fields, then I
propose we get rid of them and save bytes in the header.  If it does matter,
then lets define them properly and avoid confusion.